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ABSTRACT 

The  need  for  a  project  information  and  control  system  at 
FNOC  was  examined.  Personal  interviews  and  checklists  were 
used  to  determine  user  requirements.  Several  manual  and 
automated  alternatives  were  presented.  The  author  concluded 
that  the  purchase  of  a  software  package,  would  in  all  prob- 
ability, be  the  most  efficient  and  effective  alternative. 
Several  packages  were  evaluated  and  3  packages  were  finally 
presented  for  more  extensive  review  by  FNOC  staff. 


TABLE  OF  CONTENTS 

I.  INTRODUCTION 9 

II.  REVIEW  OF  PROBLEMS  IN  SOFTWARE  PROJECT  MANAGEMENT 11 

III.  OVERVIEW  OF  FNOC  OPERATIONS 23 

IV.  NATURE  OF  THE  PRDBLEM 28 

A.  PAST  HANDLING  OF  PROJECTS 28 

B.  CURRENT  HANDLING  OF  PROJECTS 29 

C.  FNOC  PROJECT  ENVIRONMENT 31 

V.  METHODOLOGY 37 

A.  IDENTIFICATION  OF  THE  PROBLEM 37 

B.  ANALYSIS  OF  USER'S  NEEDS 37 

C.  ANALYSIS  OF  REQUIREMENTS 38 

D.  REVIEW  OF  SOFTWARE  PACKAGES 38 

E.  PRESENTATION  OF  ALTERNATIVES 39 

VI.  REQUIREMENTS 40 

A.  OBJECTIVES  OF  THE  PROJECT  INFORMATION 

AND  CONTROL  SYSTEM 40 

B.  USER  INFORMATION  REQUIREMENTS 41 

C.  GENERAL  SYSTEMS  CAPABILITIES 46 

VII.  SOFTWARE  PACKAGE  REVIEW 47 

A.  EVALUATION  CRITERIA  USED 49 

1 .  Features 49 

2.  Technical  And  Operational 50 


a.  Hardware  Configuration 50 

b.  Higher  Level  Language 50 

c.  Operating  System 50 

d.  Ease  Of  Use 50 

e  .  Flexibility 51 

3.  Implementation  And  Maintenance 51 

a.  Immediate  Availability 51 

b.  Supplier's  Reputation  And 

Business   integrity 51 

c.  Training    And    Documentation 51 

i*.    Price 51 

B.  INTERNATIONAL  SYSTEMS1  PAC  II 52 

1.  General  Information 52 

2.  Cost  Information 55 

3.  Additional  Information 56 

C.  NICHOLS*  N5500 57 

1.  General  Information 57 

2.  Cost  Information 59 

3.  Additional  Information 60 

D.  MSP»S  PROJECTMANAGER 61 

1.  General  Information 61 

2.  Cost  Information 63 

3.  Additional  Information 63 


E.  OTHER  PACKAGES  EXAMINED 64 

VIII. ALTERNATIVE  COURSES  OF  ACTION 65 

A.  MANUAL  ALTERNATIVES 65 

B.  AUTOMATED  ALTERNATIVES 67 

IX.   CONCLUSION  AND  RECOMMENDATIONS 73 

APPENDIX  A  Requirements  Checklist 78 

LIST  OF  REFERENCES 83 

INITIAL  DISTRIBUTION  LIST 85 


LIST  OF  FIGURES 

1.  Error  Detection  And  Design  Phase 16 

2.  Naval  Oceanography  Command  Organization 26 

3.  FNOC  Products 27 

4.  FNOC  Priorities 33 

5.  Projects  And  PLans  Summary 34 

6.  FNOC  Project  Matrix  Organization 35 

7.  FNOC  Operational  Organization 36 

8.  Pac  II  Functions 53 


PREFACE 

Throughout  this  thesis  the  reader  will  find  three  cate- 
gories of  statements.   Scientific  facts  are  those  statements 
that  are  supported  by  scientific  research  in  the  field. 
These  statements  can  be  identified  by  a  direct  reference. 
Authors  opinions  are  specifically  identified  as  such.   All 
other  statements  can  be  classified  as  General  management 
lore.   This  type  of  statement  refers  to  generally  accepted 
theory  in  the  management  field;  however  it  is  unsupported  by 
scientic  research. 


I.  INTRODUCTION 

In  an  environment  characterized  by  increased  numbers  of 
projects,  drastic  increases  in  demands  for  information,  and 
strong  limitations  on  personnel,  computer,  and  financial 
resources,  Fleet  Numerical  Oceanographic  Central  (FNOC) , 
must  look  at  alternative  courses  of  action  to  maintain  an 
effective  level  of  performance  in  project  management. 

It  is  the  intent  of  the  author  to  examine  the  need  and 
information  requirements  for,  project  information  and  con- 
trol system  (PICS)  at  FNOC.  This  system  should  not  only  pro- 
vide for  the  flow  of  pertinent  project  information  to  top 
management;  but  also  assist  the  project  manager  and  other 
middle  managers  in  estimating,  assignment,  and  scheduling  of 
project  tasks  and  resources.   Alternative  courses  of  action 
will  be  identified  and  available  software  packages  examined, 
to  determine  their  capability  of  meeting  those  requirements. 

This  document  will  provide  to  FNOC  management  assistance 
in  selecting  the  appropriate  course  of  action  as  well  as 
providing  a  preliminary  analysis  of  user  requirements. 

Prior  to  examination  of  FNOC's  project  management  needs, 
a  review  of  the  literature  relevant  to  project  management 


will  be  provided.  Specifically,  there  will  be  an  examination 
of  several  of  the  problems  associated  with  software  project 
management.   An  awareness  of  these  problems  will  assist  the 
project  manager  in  visualizing  the  importance  of  effective 
project  control. 
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II.  REVIEW  OF  PROBLEMS  IN  SOFTWARE  PSOJECT  MANAGEMENT 

An  increasing  percentage  of  DOD  monies  are  allocated  for 
direct  software  acquisition  or  embedded  software.  In  1977, 
the  United  States  government  estimated  the  cost  of  software 
development,  testing,  and  maintenance  to  be  about  $4  billion 
per  year.  At  that  time  the  government  owned  approximately 
$25  billion  worth   of  currently  used  software.  [Ref.  1] 
Overruns  of  100%  in  both  cost  and  delivery  time  have  not 
been  uncommon  occurrences  in  software  projects;  and  in  fact, 
there  have  been  cases  of  total  failure  to  develop  systems. 

There  has  been  a  great  deal  of  attention  and  speculation 
as  to  the  cause  of  these  problems.  It  is  the  author's  con- 
tention that  effective  project  management  on  the  part  of  the 
contracting  project  manager  can  minimize  and  perhaps  elimi- 
nate most  of  these  problem  areas. 

A  review  of  the  literature  surfaced  several  problem 
areas  in  software  project  management.  These  problems  are 
presented  here,  together  with  information  for  the  project 
manager  who  desires  to  minimize  the  risk  of  project  failure. 
Certainly  the  awareness  alone,  of  potential  problems. 
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will  increase  the  effectiveness  of  the  project  manager,  and 
provide  direction  toward  project  success. 


PROBLEM: 

Poor  accountability  and  control  structure,  such  as: 

*  inappropriate  measures  of  effectiveness 

*  minimizing  development  costs  and  schedule 

*  emphasis  on  percent  coded 


The  first  method  of  control  starts  with  the  organiza- 
tional structure.   Usually  the  project  organization  is  set 
up  to  meet  a  specific  objective  and  it  dissolves  after  it 
has  been  accomplished.  This,  in  itself  can  create  a  problem. 
The  manager  may  not  be  fully  aware  of  the  skills  of  the  pro- 
gramming teams.  The  host  organization  must  therefore  strive 
to  maintain  accurate  documentation  as  to  those  abilities. 

Managers  must  also  decide  on  a  mangement  system.  There 
are  many  automated  management  control  systems  available  to 
assist  a  project  manager;  however,  it  should  be  remembered 
that  they  must  fit  the  organization,  and  that  simply  because 
they  have  been  used  with  great  success  by  others  ,  does  not 
guarantee  their  success  in  all  structures  or  projects.  This 
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is  a  point  that  many  managers  fail  to  take  into  account  when 
they  are  looking  for  that  magic  control  method.   In  matching 
a  method  to  the  organization  the  manager  must  take  into 
account  such  things  as  whether  or  not  project  management  is 
linear  or  matrix  oriented,  what  item  the  organization  is 
most  interested  in  tracking,  and  what  levels  of  reporting 
are  required. 

Establishment  of  a  project  control  room  to  centralize 
information  needed  by  the  project  team  might  prove  to  be  of 
value  to  the  organization.  Some  of  these  items  include: 
documentation,  master  schedules,  status  reports,  change 
authorizations,  budget,  systems  flow  charts,  edit  rules,  and 
user  training  information.   Consideration  might  also  be 
given  to  the  establishment  of  a  project  control  secretary 
position. 

Emphasis  on  percent  coded  tends  to  get  people  coding  too 
early  and  key  activities  such  as  requirements  and  design 
validation,  test  planning  and  draft  of  user  documents  are 
neglected.  It  is  also  true  that  percent  coded  is  not  indica- 
tive of  where  the  project  is  relative  to  the  schedule.  It  is 
extremely  subjective.  To  combat  this  problem,  key  milestones 
should  be  set.  These  must  be  measurable  milestones.   For 
example,  milestone  1  might  be  acceptance/approval  of  design 
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criteria  by  the  user.  Involvement  of  the  user  early  in  the 
project  and  throughout  its  existence  will  help  to  keep  the 
project  on  track  and  hopefully  surface  user  problems  early 
in  the  project. 

Structured  programming  techniques;  specifically  top-down 
design,  provides  a  procedure  for  organizing   and  developing 
the  control  structure  of  a  program  in  a  way  which  focuses 
attention  early  to  the  critical  issues  of  integration  and 
interface  identification  and  definition. 


r~      -      — 

■ 

PROBLEM: 

Soft 

.ware 

requirements 

speci 

f ications 

(if 

they 

exist) 

are 

ofter 

i   ambiguous. 



j 

These  requirements  must  be  written  by  personnel  knowled- 
gable  in  both  the  systems  requirements  and  software  develop- 
ment. This  is  often  not  the  case,  especially  where  embedded 
software  is  involved. 

Technology  can  be  of  assistance  here.  Machine  analyzable 
software  requirements  systems  are  available.  The  pioneer  in 
this  technology  was  ISDOS,  developed  by  Teichroew  at  the 
University  of  Michigan  [Ref.  2].   although  it  was  developed 
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primarily  for  business  systems  applications;  the  United 
States  Air  Force  is  currently  using  and  sponsoring  exten- 
sions to  ISDOS  under  the  computer  aided  requirements  analy- 
sis (CABA)  program.  Another  even  more  extensive  and  powerful 
system  is  one  developed  under  the  software  requirements 
engineering  program  (SREP)  by  TRW  for  the  United  States  Army 
Ballistic  Missile  Defense  Advanced  Technology  Center.   Even 
these  automated  systems  have  limitations  however;  the  capa- 
bilities to  represent  large  file  processing  and  man-machine 
interactions  are  limited.  They  are  a  start  however. 

Often  a  project  manager  will  inherit  a  project  which  is 
not  adequately  defined.  Realizing  this  and  taking  immediate 
steps  to  remedy  the  problem  is  necessary  to  project  success. 
The  extra  time  spent  at  this  point  will  pay  off  in  the  end. 
Because  of  the  nature  of  software  development,  errors 
detected  early  in  the  cycle  are  less  costly  then  those  dis- 
covered in  later  phases,  Figure  1  [ Ref .  3].  A  project  man- 
ager must  avoid  the  temptation  to  allow  detailed  design  and 
coding  to  begin  prior  to  establishment  of  user  requirementts 
and  an  overall  plan.  The  extra  time  spent  in  the  definition 
and  design  phase  will  be  time  well  spent  if  it  minimizes  the 
likelihood  of  problems  in  later  phases. 
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ERROR  DETECTION  AND  DESIGN  PHASE 


changes  in  software  in 
succeeding  phases  of 
development  drive  up  the 
cost  exponentially 
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PROBLEM: 

Software  testing  and  reliability  activities  are 
often  not  considered  until  the  code  has  been 
ran  for  the  first  time  and  found  not  to  work. 


In  general  the  cost  of  testing,  40%-50%  of  the  devlop- 
ment  effort,  is  due  to  the  high  cost  of  reworking  the  code 
at  this  late  phase  of  the  cycle  [  Ref .  4].   There  is  a  great 
deal  of  wasted  effort  resulting  from  the  lack  of  an  advanced 
test  plan  to  efficiently  and  effectively  guide  testing 
activities. 

The  development  people  must  consider  the  testability  of 
their  design  and  ensure  that  code  can  be  exhaustively  tested 
before  the  next  higher  level  of  code  is  added.  Early  loca- 
tion and  correction  of  errors  results  in  much  more  reliable 
programs.  A  solid  test  plan  should  provide  for  an  indepen- 
dent validation  team  to  be  established  at  the  beginning  of 
the  project. 

The  consequences  of  undetected  errors  can  range  from 
minor  to  disastrous.   A  well  known  example  of  the  latter  was 
the  Mariner  1  interplanetary  probe.   The  absence  of  one  bar 
over  a  letter  in  a  computational  equation  resulted  in  a 
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unrecoverable  problem,  left  no  alternative  but  to  destruct 
the  $18.5  million  dollar  rocket  shortly  after  launch.  [Ref.  5] 

Reliability  can  be  improved  by  imposing  standards  on 
programming  style  for  all  code  written.  Structured  program- 
ming has  a  lot  to  contibute  in  this  area.  Structured  pro- 
gramming involves  dividing  a  complex  program  into 
progressively  smaller  modules,  each  of  which  has  a  well 
defined  task.  The  most  refined  modules  are  small  and  logi- 
cally straight  forward.  They  have  limited  control  structures 
and  one  entry  and  exit  point.  The  conciseness  of  the  modules 
allows  the  programmer  to  use  formal  mathematics  to  prove  the 
correctness  of  the  code. 


__         

PROBLEM: 

Cost  estimates 

in  software  projects  are  often 

incomplete  and 

grossly  inaccurate. 

There  is  always  the  element  of  risk,  especially  on 
projects  that  push  the  state  of  the  art.  Estimating  hardware 
costs  has  followed  established  methods,  software  on  the 
other  hand,  is  seldom  handed  to  a  software  estimating  group. 
In  fact,  software  estimating  seldom  follows  any  scientific 
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procedures,  with  perhaps  the  exception  of  those 
organizations  utilizing  PERT/CPM*. 

The  DOD  is  currently  evaluating  macro  and  micro  techni- 
ques for  estimating  resources  required  for  ADP  projects.  The 
macro  technique  provides  an  overall  lump  sum  estimate  of 
manpower  and  costing  factors  for  the  entire  systems  life 
cycle.   The  micro  technique  provides  detailed  manpower  and 
costing  for  each  phase  of  the  life  cycle  [Ref.  6]. 

Studies  by  industry  have  concluded  that  there  are  no 
simple  universal  rules  for  costing  software  accurately  and 
that  to  estimate  it  accurately  it  is  neccesssary  to  under- 
stand the  nature  of  the  individual  program  [Ref.  7]. 

It  would  appear  that,  the  problem  with  software  cost 
estimates  is  that  until  we  have  more  standardization  of 
procedures  in  the  software  industry,  the  estimates  will  con- 
tinue to  be  grossly  inaccurate  due  in  part  to  the  varying 
programming  methods. 

One  pitfall  to  avoid  in  worrying  about  software  costs  is 
that  of  concentrating  too  much  on  reducing  software  develop- 
ment costs.  What  really  needs  to  be  reduced  is  software  life 
cycle  costs.  Instead,  we  too  often  find  project  managers 


*For  additional  information  on  PERT/CPM  see  Cleland ,D. L. 
and  King, W.R..  systems  Analysis  And  Project  Management, 
McGraw-Hill: 196a,  chapter  is. 
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making  a  lot  of  trade-offs  during  the  software  development 
to  meet  schedule  and  cost  constraints.  Many  of  those  trade- 
offs trade  maintainability  for  speed  of  development. 

In  a  discussion  during  the  1973  Symposium  on  the  High 
Cost  of  Software,  it  was  pointed  out  that  the  avionics  soft- 
ware in  the  Air  Force  cost  something  like  $75  per  instruc- 
tion to  develop;  however,  the  maintenance*  of  the  software 
had  costs  up  to  $4000  per  instruction  [Ref.  8]. 

The  trend  projected  through  1985  is  for  software  costs 
to  continue  to  rise  [Ref.  9].  In  part,  this  is  due  to  an 
increase  in  size  and  complexity  of  projects  and  an  overall 
increase  in  the  rate  of  technological  change.   The   industry 
is  currently  pouring  R&D   money  into  exploration  of  auto- 
mated methods.  Some  progress  has  been   made  in  this  area; 
however  in  the  author* s  opinion,  it  will  be  some  time  before 
wide  spread  use. 


PROBLEM: 


Schedule  slippage 


♦Maintenance  includes  all  costs  after  the  initial  devel- 
opment effort  associated  with  keeping  the  software  in  opera- 
tion   (including    revisions/upgrades)  . 
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Schedule  slippage  results  for  a  number  of  reasons.  Nota- 
ble among  them  is  personnel  related  problems.  Skill  levels 
among  programmers  vary  greatly,  also  the  amount  of  time  nec- 
cessary  to  program  in  different  languages  varies.  These  fac- 
tors together  with  the  degree  of  complexity  of  the  system 
required,  must  be  considered  by  the  project  manager  in  mak- 
ing the  schedule  estimate.  Most  often  a  project  manager 
inherits  a  project  for   which  these  estimates  have  been  made 
prior  to  the  assignment  of  the  project  team  and  the  project 
manager  will  have  to  make  adjustments  and  recommednations  to 
deal  with  inappropriate  estimates. 

Project  managers  must  rid  themselves  of  the  idea  that  if 
they  get  behind  schedule,  adding  more  programming  staff  will 
solve  their  problem.  Dn  the  contrary,  in  many  instances  it 
will  no  doubt  have  quite  the  opposite  affect  That  is,  the 
new  staff  will  have  to  be  brought  up  to  speed  and  this 
entails  pulling  experienced  programmers  off  the  job  for  this 
purpose,  resulting  in  even  greater  delays.   Brooks*  Law 
states:  "Adding  manpower  to  a  late  software  project  makes  it 
later  "  [Ref .  10]. 

It  is  obvious  that  the  preceding  problems  are  not  inde- 
pendent, and  that  difficulty  in  any  one  of  them  has  a  signi- 
ficant impact  on  each  of  the  others. 

21 


In  summary,  the  difference  between  software  project 
successes  and  failures  has  most  often  been  traced  to  good  or 
poor  .practices  in  software  management.   These  problems  can 
be  divided  into  the  following  three  major  areas: 

POOR  PLANNING:   Generally  this  leads  to  large  amounts  of 
wasted  effort  and  idle  time  because  of  tasks  being  unne- 
ceassarily  performed,  overdone,  poorly  synchronized,  or 
poorly  interfaced. 

POOR  CONTROL:   A  plan  is  useless  when  it  is  not  kept  up  to 
date  and  used  to  manage  the  project.  Also,  the  selection 
of  the  correct  control  method  for  the  organization  is  cri- 
tical for  success. 

POOR  RESOURCE  ESTIMATION:   Without  a  firm  idea  of  how  much 
time  and  effort  a  task  should  take,  the  manager  is  in  a 
poor  position  to  exercise  control.  Improper  assignment  of 
personnel  to  tasks  can  cause  cost  and  schedule  overruns. 
In  short,  the  key  to  project  success  lies  with  the  man- 
agement team  and  the  efforts  they  make  to  establish  project 
control.  In  the  following  chapters,  the  author  will  examine 
FNOC"s  project  management  needs  in  relation  to  these  and 
other  considerations. 
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III.  OVERVIEW  OF  FNOC  OPERATIONS 

FNOC  provides  a  wide  spectrum  of  numerical  ,  meterologi- 
cal, and  oceanographic  products  to  worldwide  users  on  a 
real-time  basis.  A  multi-mainframe  computer  center  is  used 
to  execute  report  processing,  analysis,  prediction,  display 
and  research  jobs  as  a  major  part  of  the  command's  mission. 
A  standard  sequence  of  scheduled  jobs  known  as  the  opera- 
tional run   (OPS  RUN)  is  processed  every  12  hours  to  accom- 
plish a  complete  global  meterological  and  oceanographic 
analysis  and  prognosis  cycle.  A  database  of  current  environ- 
mental observations  and  a  complete  set  of  climatological 
information  is  used.  The  goal  of  the  OPS  RUN  being  to  pro- 
vide analysis  and  forecast  fields  and  data  for  transmission 
to  DOD  facilities  and  users  as  soon  as  possible  after  the 
receipt  of  raw  observations. 

FNOC  is  an  integral  part  of  the  naval  oceanographic  and 
meterological  support  system.  See  Figure  2.  Environmental, 
meterological,  oceanographic  observations  (raw  data)  and 
requests  for  services  come  into  FNOC,  the  primary  production 
facility,  via  the  Automated  Weather  Network  (AWN),  AUTODIN, 
AflSAT,  or  the  Suitland  data  line.   The  raw  data  is  quality 
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checked,  sorted,  and  edited  by  computer  programs,  after 
which  the  analysis,  prognosis,  and  applications  programs  are 
run  and  the  output  processed  and  placed  in  the  integrated 
database. 

A  sophisticated  series  of  prediction  programs  generate 
forecast  variables  such  as  wind,  temperature,  pressure, 
moisture,  and  sea  heights,  to  provide  the  fleet  with  a  four 
dimensional  measure  of  the  air-ocean  environment  in  which 
they  operate.  These  products  are  distributed  to  the  four 
weather  centrals  (Pearl, Guam  Norfolk,  and  Rota)  via  the 
Naval  Environmental  Data  Network  (NEDN)  and  the  Naval  Envi- 
ronmental Display  System  (NEDS) .  The  weather  centrals  tailor 
these  products   before  disseminating  them  to  end  users.  In 
some  cases  FNOC  provides  environmental  products  directly  to 
the  end  users. 

The  products  produced  by  FNOC  are  of  two  basic  types; 
routine/  scheduled  or  tailored.  Special  requests  for  tai- 
lored  products  are  based  on  changing  fleet  or  other  opera- 
tional committments.   These  products  are  transmitted  via  the 
telecommunications  system.   Figure  3  is  a  listing  of  some  of 
the  products  currently  provided  by  FNOC.  A  primary  emphasis 
in  oceanogr aphic  modeling  is  support  of  antisubmarine  war- 
fare forces.  FNOC  provides  fleet  units  with  expected 
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detection  ranges  for  each  of  their  acoustic  sensor  systems, 
no  matter  where  they  are.  Currently,  satelite  processing  is 
becoming  the  focus  of  attention,  as  a  means  of  providing  a 
more  accurate  database. 

To  provide  all  these  services;  FNOC  maintains  twenty- 
four  hour  computer  center  operations,  manned   by  military 
and  civilian  personnel.  There  is  considerable  development  of 
advanced  techniques  and  capabilities  in  data  processing, 
ocean  and  atmospheric  analysis,  prediction,  display,  appli- 
cations and  communications.  There  is  continual  planning  and 
implementation  of  computer  systems  upgrades. 

The  project  approach  is  frequently  used  to  meet  new  and 
changing  requirements  at  FNOC;  hence,  there  is  a  sound  rea- 
son for  seeking  to  optimize  the  project  management  proce- 
dures and  controls. 
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FNOC  PRODUCTS 

ROOTIHE 

area  forecasts 

wind  and  sea  warnings 

terminal  and  local  forecasts 

oceanographic  outlooks 

acoustic  predictions 

analysis  and  prognosis  for  atmosphere  and  ocean 

TAILORED 

optimum  track  ship  routes  (OTSR) 

enroute  ship  weather  forecasts  (WEAX) 

refractive  effects 

ballistic  wind  and  densities 

amphibious  forecasts 

environmental  briefings 

climatological  studies 

optimum  path  aircraft  routing  (OPARS) 

acoustic  predictions 

search  and  rescue  (SAR) 

Figure  3 

._., _ .                        ,,_,..,,      ._.  
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IV.  NATURE  OF  THE  PROBLEM 

A.   PAST  HANDLING  OF  PROJECTS 

In  late  1976  FNOC  adopted  a  computerized  descriptive 
list  of  projects.   This  listing  was  originally  developed  for 
use  exclusively  by  the  Data  Integration  Department.   This 
action  constituted  the  first  step  in  the  development  of  a 
MIS  to  assist  in  project  control.  This  list  was  only  a 
beginning  and  fell  far  short  of  fullfilling  the  needs  of  the 
command.  Due  to  other  commitments  and  limited  resources, 
little  progress  was  made  in  improving   the  system.  There 
were  several  serious  problems  with  the  system;  the  report 
format  was  not  well  defined,  file  updates  were  irregular  and 
incomplete,  and  milestone  dates  were  passed  without  comment 
or  explanation.   A  serious  problem  worth  discussing,  was  the 
fact  that  the  system  lacked  middle  management  support.  The 
primary  reasons  given  for  dissatisfaction   with  this  MIS 
were  that  it  was  a  cumbersome  and  ill-defined  system  and 
that  it  provided  very  little,  if  any,  benefits  to  the  middle 
manager. 

The  MIS  received  considerable  command  attention  between 
1976  and  1977;  however,  commitment  of  personnel  resources  to 
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solve  its  many  problems  was  lacking.  After  this  period  the 
MIS  received  only  ocasional  command  level  emphasis  and  by 
mid  1979  there  was  considerably  less  insistence  on  keeping 
the  information  updated.  By  1980  the  commanding  officer  had 
taken  the  HIS  out  of  operation  completely. 

It  would  seem  that,  by  all  development  standards,  this 
MIS  was  doomed  from  the  start.  Installing  an  information 
system  is  a  complex  job.   It  involves  an  examination  of  the 
entire  structure  of  the  organization  and  the  information 
flow.  Clearly,  this  was  not  done  in  this  case.   The  need 
exists  for  more  planning  and  some  definite  attention  to  the 
organizational  problems. 

B.   CURRENT  HANDLING  OF  PROJECTS 

Currently  there  is  no  automated  MIS,  neither  are  there 
any  well-defined  procedures  for  project  control  and 
reporting. 

Several  manual  reporting/tracking  mechanisms  have  been 
tried  recently,  including  the  completion  of  the  form  in 
Figure  4.   These  represent  major  milestones/tasks  to  be 
accomplished  during  the  periods  indicated.  These  tasks  are 
listed  by  department,  staff  position,  and  major  projects. 
Although  only  a  crude  mechanism;  it  does  force  involved  per- 
sonnel to  give  some  thought  to  their  own  priorities  in 
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relation  to  the  command's  priorities.   The  problem  is,  all 
personnel  involved  do  not  contribute;  therefore  the  informa- 
tion is  not  complete. 

A  second  mechanism  currently  in  use  is  the  Projects  and 
Plans  Summary,  Figure  5,  initiated  during  the  spring  of 
1981.   The  Plans  and  Programs  Officer  has  identified  8  gen- 
eral project  areas  based  on  function;  within  these  areas 
there  may  be  many  projects.  This  summary  identifies  primary 
resources  involved  and  scheduled  events,  activities,  and 
milestones  for  the  current  fiscal  year  and  beyond.  It  is 
strictly  a  manual  effort  and  the  initial  summary  took  three 
days  of  concentrated  effort  to  produce  (this  time  does  not 
include  its  planning  time) .  These  dates  are  monitored  using 
strictly  manual  methods  which  requires  constant  vigilance 
and  attention  to  detail.  It  is  highly  likely  that   when  the 
current  Plans  and  Programs  Officer  leaves  FNOC  (in  the  fall 
of  1981)  this  summary  will  cease  to  exist. 

Reporting  of  development  projects  is  handled  via  the 
Work  Unit  Package  which  is  submitted  twice  a  year  and 
updated  only  for  major  changes.   This  report  is  produced  on 
a  word  processor;  however  no  data  manipulation  is  done. 
This  is  due  in  part  to  references  24  and  25,  which 
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specifically  prohibit  use  of  word  processing  equipment  for 
data  manipulation  without  prior  approval. 

C.   FNOC  PROJECT  ENVIRONMENT 

FNOC  utilizes  a  matrix  organization  for  project  manage- 
ment.  Figure  6  represents  the  general  structure  of  this 
organization,  while  Figure  7  depicts  FNOC's  operational 
organization.   Matrix  management  is  based  on  the  concept  of 
pulling  together  technical  and  managerial  talent  into  a  team 
to  operate  without  the  limits  of  discipline  or  organiza- 
tional lines.   Matrix  relationships  are  far  more  complex 
than  traditional  functional  relationships  in  which  the  rela- 
tionships are  predominantly  vertical  with  few,  if  any, 
cross- functional  aspects.  Each  major  group  or  department  is 
primarily  concerned  with  its  own  goals.  The  matrix  organiza- 
tion changes  these  traditional  patterns  by  creating  new  ver- 
tical, horizontal,  and  diagonal  relationships  among  its 
members.   Communication  becomes  far  more  critical  in  a 
matrix  organization;  thus,  tight  project  control  and 
reporting  becomes  increasingly  crucial. 

The  department  head*s  goal  orientation  must  also  change 
due  to  the  matrix  organization,  in  that  they  must  be  con- 
cerned with  project  goals  in  addition  to  their  functional 
goals.  [Ref.  11 ]  In  a  matrix  organization,  the  functional 
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specialist  is  placed  in  the  difficult  situation  of  taking 
direction  from  two  managers;  therefore,  if  there  are  not 
well  defined  channels  of  authority,  there  is  potential  for 
considerable  conflict.  Irregardless  of  this,  due  to  the 
nature  of  the  project  environment,  matrix  management  appears 
to  be  the  proper  choice.  The  built-in  conflict,  if  handled 
properly,  tends  to  enhance  initiative  among  the  participants 
as  they  compete  for  the  limited  resources. 

Matrix  management  is  indeed  difficult;  however,  it  faci- 
litates the  coordination  and  integration  of  many  project 
activities,  and  provides  the  flexibility  required  in  a  com- 
plex multifunction  environment  such  as  FNOC* 

Two  staff  positions  were  established  to  aid  in  project 
planning  and  control.   The  PLans  and  Programs  Officer,  res- 
ponsible primarily  for  long  range  planning  and  budgeting, 
and  the  Development  Coordinator,  responsible  for  coordinat- 
ing R&D  activities  under  work  unit  funding. 


*For  additional  reading  on  matrix  management  consult 
reference  1 1 . 
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FNOC  PROJECT  MATRIX  ORGANIZATION 


functional  elements 


LEGEND 

CO  Commanding  Officer 

PM  Project  Manager 

DH  Department  Head 

FS  Functional  Specialist 
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V.     METHODOLOGY 

This   study   focused   on   the   identification   of    user 
requirements   for   PICS. 

A.  IDENTIFICATION  OF  THE  PROBLEM 

The  initial  concentration  of  this  thesis  was  to  formu- 
late and  describe  a  problem  statement  for  project  manage- 
ment at  FNOC.   Further  discussion  then  focused  on  the 
various  causes  that  had  combined  to  produce  the  problem.  The 
discussion  also  presented  details  about  the  past  and  current 
project  management  procedures  .   Having  made  a  largely  sub- 
jective determination  of  the  problem,  the  next  step 
involved  an  analysis  of  the  user's  needs. 

B.  ANALYSIS  OF  USER'S  NEEDS 

Twelve  key  FNOC  personnel  were  selected  on  the  basis  of 
their  senior  management  positions  at  FNOC  or  their  expertise 
and  longevity  in  the  project  management  environment.  Indivi- 
dual PERSONAL  INTERVIEWS  were  conducted  with  each  of  the 
tweleve  individuals.  The  question  posed  was;  what  informa- 
tion requirements  and/or  capabilities  would  you  like  to  see 
in  a  project  management  and  control  system  at  FNOC  (either 
automated  or  manual) .  Individuals  responses  were  not 
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revealed  to  other  interviewees  and  the  interviewer  limited 
her  input,  so  as  not  to  impose  her  views  on  those  being 
interviewed. 

Responses  from  interviews  were  consolidated  in  an  uned- 
ited CHECKLIST  form  and  distributed  to  all  FNOC  personnel 
directly  involved  in  project  management  at  some  level.  Those 
involved  in  the  personal  interviews  were  also  asked  to  com- 
plete the  checklist  inorder  to  validate  the  information  and 
assure  that  the  interviewer's  intarpretation  of  their  origi- 
nal responses  was  correct. 

C.  ANALYSIS  OF  REQUIREMENTS 

Check  list  responses  were  classified  as  to  management 
level  (CO/XO/  DEPT  HEAD/PRINCIPAL  INVESTIGATOR/PROJECT 
MANAGER)  and  analized.   Items  that  were  not  felt  to  be 
necessary  were  deleted  and  a  comprehensive  list  of  require- 
ments was  identified  as  the  minimum  necessary  for  a  Project 
Information  and  Control  System  (PICS). 

D.  REVIEW  OF  SOFTWARE  PACKAGES 

The  criteria      to   be   satisfied   by   a    project   managment 
software  package  was  outlined  and   a   survey   of   available 
software  packages  was   made.    Each   software  package   was 
compared  to   the    established   criteria   to  select   the    most 
appropriate    package/packages. 
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This  preliminary  screening  was  based  on  the  established 
general  system  requirements.  The  intention  was  to  reduce  the 
number  of  packages  being  considered  to  those  that  appeared 
most  likeley  to  meet  the  needs  of  the  organization. 

E.   PRESENTATION  OF  ALTERNATIVES 

A  variety  of  feasible  alteratives  were  identified  in  an 
attempt  to  cover  the  entire  spectrum  of  possibilities. 
Their  advantages  and  disadvantages  were  examined  and  dis- 
cussed to  give  the  executive  a  view  of  their  relative  value. 
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VI.  REQUIREMENTS 

A.   OBJECTIVES  OF  THE  PROJECT  INFORMATION  AND  CONTROL  SYSTEM 
The  overriding  objective  of  most  organizations  in  imple- 
menting an  automated  information  system,  is  to  increase  the 
overall  effectiveness  of  the  organization  involved.   In  the 
private  sector,  this  translates  into  increased  profits.   In 
the  public  sector,  it  is  not  as  easily  measured. 

In  order  to  define  more  specific  objectives  for  the 
automated  system,  the  author  conducted  personnel  interviews 
with  FN03  personnel.   These  interviews,  together  with  the 
author's  personal  experience,  were  then  used  to  describe  the 
following  overall  objectives  for  an  automated  project  man- 
agement and  control  system. 

1.  Must  require  minimal  inputs  to  the  system,  that  is, 
once  the  initial  system  has  been  established,  it  should  be 
no  more  cumbersome  to  maintain  then  current  record 
keeping. 

2.  Must  deliver  information  to  the  appropriate  manager 
when  it  is  needed,  so  that  situations  requiring  immediate 
decisions  can  be  controlled,  and  situations  that  are  not 
pressing  can  be  deffered,  but  not  to  the  point  of  loss  of 
control. 
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3.  Must  provide  for  simultaneous  horizontal  and  vertical 
dissemination  of  necessary  information,  so  that  top  level 
management  and  every  operating  department,  will  be  ade- 
quately informed.  In  particular,  it  is  important  that  the 
vertical  dissemination  of  information  follow  only  the 
necessary  path.   Furthermore,  information   sent  in  a  ver- 
tical direction  should  be  directed  only  as  low/high  as 
required  to  make  or  retract  a  decision. 

4.  Must  reduce  reams  of  information  to  meaningful  facts 
for  management  to  use  in  planning  the  future  operations  of 
the  organization. 

B.   USER  INFORMATION  REQOIREMENTS 

One  of  the  first  steps  in  developing  or  obtaining  a 
software  system,  is  to  define  the  user's  requirements.   This 
is  far  more  involved  than  it  sounds.   After  almost  twenty 
ysars  of  attention,  it  is  still  often  the  case,  that  compu- 
ter based  application  systems  are  developed  behind  schedule, 
over  cost,  don*t  do  as  much  as  premised,  and  don*t  satisfy 
the  user  needs.   At  the  heart  of  this  problem,  is  the  fact 
that,  often  the  requirements  for  these  applications  were 
never  stated  accurately  or  completely  in  the  first  place. 
The  fact  that  one  may  never  reach  perfection  in  this  area 
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should  not  prevent  an  all  out  effort  to  identify  require- 
ments as  completely  as  possible. 

The  importance  to  project  success  of  getting  these 
requirements  right,  can  not  be  over  stated.   If  the  require- 
ments are  not  complete  or  correct,  the  system  may  not  be 
usable.   If  the  system  is  salvagable,  the  cost  incurred  in 
correcting  the  system  may  be  excessive  and  the  additional 
time  required,  could  be  time  better  spent  elsewhere.  There 
is  also  the  possibility  that  the  organizational  effective- 
ness will  be  decreased,  due  to  either  not  having  a  workable 
system,  or  having  one  that  only  partially  meets  their  needs. 

Certainly  our  record  of  customer  satisfaction  is  not 
good.   For  that  reason,  we  must  be  aware  of  the  problems  and 
recognize  that  a  substantial  number  of  errors  will  exist  in 
most  requirements  statements,  unless  specific  action  is 
taken  to  identify  and  remove  them  [Ref.  12]. 

There  are  three  basic  approaches  to  information  require- 
ments analysis  [Ref.  13]. 

DIRECT  ANALYSIS,  which  involves  interaction  with  the  user 
to  identify  decision  processes  and  information  elements. 
INDIRECT  ANALYSIS  is  the  evaluation  of  data  utilization, 
such  as  observing  people  or  reports,  in  order  to  infer 
information  requirements. 
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HYBRID  ANALYSIS,  which  is  a  combination  of  direct  and 

indirect. 

The  author  utilized  the  hybrid  analysis  approach, 
together  with  her  personal  experience.  It  must  be  emphasized 
however;  that  this  is  simply  a  preliminary  analysis  of  user 
requirements,  and  that  a  more  extensive  analysis  should  be 
undertaken  if  the  decision  is  made  to  pursue  this  idea 
further. 

Information  for  data  items  was  collected  from  inter- 
views, check  list  responses,  and  the  authors  experience.  It 
was  not  felt  necessary  to  include  every  data  item  from  each 
source  of  information.  The  amount  of  effort  needed  to  obtain 
and  enter  some  items  of  data,  coupled  with  the  increased 
storage,  capacity  necessary,  and  subsequent  longer  retrieval 
times,  far  overshadowed  the  possible  benefit  that  could  be 
gained  from  having  that  information  on  line. 

The  author's  value  judgements  were  used  to  define  a  com- 
prehensive requirements  list  that  would  be  useful  without 
being  overly  demanding  on  resources.  Future  evaluations  of 
update  and  usage  rates  of  these  data  items  should  be  made 
once  a  system  is  in  use,  to  reduce  the  size  of  the  database 
by  eliminating  unused  items. 
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The  following  are  deemed  minimal  information 
requirements  for  an  automated  project  management  and  control 
system. 

*  A  means  of  establishing  and  tracking  milestones,  actual 
versus  planned. 

*  A  method  to  provide  information  on  available  resources, 
personnel,  monetary,  and  computer,  and  their  utilization 
and/or  allocation. 

*  A  means  of  indicating  priority  of  projects. 

*  A  means  of  establishing  and  promulgating  lines  of 
authority  and  responsibility. 

*  The  ability  to  include  narrative  comments. 

*  A  means  of  indicating  time/scheduling  information. 

*  A  means  to  break  the  project  up  into  tasks  and  subtasks 
for  tracking  and  reporting. 

Reference  14  and  appendix   A  ,  contain   more  detailed 
requirements  for  recommended  data  elements. 

It  is  recognized  that  these  requirements  differ  with 
each  level  of  management  as  does  the  degree  of  detail  of  the 
information.   Anthony,  [Ref.15]  in  his  framework  for  plan- 
ning and  control,  focuses  on  three  categories  of  decisions 
which  can  be  translated  to  the  levels  of  project  management 
at  FNOC.  They  are: 

STRATEGIC  PLANNING:   which  is  equivalent  to  the  type  of 
decisions  made  at  the  staff  level  (CO, XO, staff 


♦CRAS  (Computer  Resources  Accounting  System)  will  pro- 
vide information  related  to  EDP  usage. 
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assistants) .  They  require  only  summary  level  information 
rather  than  more  detailed  reports. 
MANAGERIAL  CONTROL:   the  key  concern  here  is  that 
resources  are  obtained  and  used  effectively  and  effi- 
ciently to  accomplish  the  defined  objectives.  In  FNOC's 
project  environment  this  can  be  equated  to  the  principal 
investigator  and  department  head.  They  require  details  of 
resource  utilization  and  milestone  information. 
OPERATIONAL  CONTROL:   at  this  level  of  decision  the  empha- 
sis is  on  assuring  that  tasks  are  carried  out  effectively 
and  efficiently.   This  equates  to  the  project  manager 
level  at  FNOC.  The  project  manager  is  concerned  with  the 
day  to  day  operations. 

In  order  to  provide  the  flexibility  necessary  to  meet 
the  diverse  needs  of  the  various  users,  this  information 
should  be  accessable  according  to  a  number  of  retrieval 
criteria,  such  as: 

*  miletones  exceeded 

*  upcoiming  milestones 

*  funding  source 

*  responsible  principle  investigator , department, division 

*  name  of  project  manager 

*  system  relationship  (ie.  PEPSU,  CCS, NEDS) 

*  priority 

*  estimated  cost 

*  duration  of  projects 
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*  classification  of  projects  (ie.  development,  operational, 
or  maintenance) 

*  resource  allocation  exceeded 

*  noncompliance  with  established  update  schedule. 

C.   GENERAL  SYSTEMS  CAPABILITIES 

Aside  from  the  information  requirements  listed  in  the 
previous  section,  there  are  a  number  of  desirable  capabili- 
ties the  system  should  have.  They  include  the  following, 
which  are  listed  according  to  relative  importance: 


*  The  ability  to  run  on  equipment  currently  available  to 
FNOC. 

*  Easy/fast  update  procedures,  requiring  little  or  no 
additional  effort  on  the  part  of  project  staff. 

*  At  least  3  levels  of  reporting;  summary,,  detailed  and 
exception.  To  assure  that  only  that  intormation  of 
interest  to  a  particular  management  level  may  be  pre- 
sented. Ackoff,  [Ref.  16]  emphasizes  that  contrary  to 
popular  belief,  managers  suffer  most  from  information 
overload  rather  than  lack  of  information. 

*  A  means  to  control  who  is  authorized  to  update/modify 
project  information  in  the  file. 

*  Backup/recovery  procedures 

*  Flexibility  in  report  formats  to  allow  individual  manag- 
ers to  get  the  information  they  require  in  a  form  that 
is  most  usefull  to  them.   It  is  critical  that  middle 

. managers  receive  some  direct  tangible  benefit  from  the 
project  management  and  control  system  if  they  are  to 
support  it. 

*  Specific  definitions  (ie.  pro ject, task,  sub- 
task,  milestaone)  so  that  all  reporting  is  done  in 
regards  to  a  common  basis. 

*  Interactive  capability  option 

*  ability  to  support  multiple  users  in  the  interactive 
mode. 
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VII.  SOFTWARE  PACKAGE  REVIEW 

Commercially  available  software  packages  are  becoming  a 
major  market  factor  in  the  data  processing  industry.  They 
have  many  advantages  over  independently  developed  applica- 
tions. Most  packages  are  well  designed  and  documented  and  if 
the  package  has  been  on  the  market  for  some  time,  there  is  a 
good  chance  that  most  of  the  serious  bugs  have  been  elimi- 
nated. Software  packages  permit  the  installation  of  a  new 
system  for  relatively  less  cost  than  that  of  in-house  devel- 
opment due  to  the  fact  that  the  cost  can  be  spread  over  many 
customers.  There  is  little  or  no  risk  of  cost  or  schedule 
overrun  usually  associated  with  software  development 
efforts.   This  allows  management  to  establish  dependable 
schedules  for  i oplementation  and  accurate  budget  plans. 

The  purchase  of  a  software  package  also  allows  the 
organization  to  utilize  the  professional  talents  of  their 
programmers  and  systems  analysts  in  the  development  of  sys- 
tems unique  to  their  organization,  rather  than  in  redevelop- 
ing systems  that  have  been  developed  by  many  before  them. 
Additionally,  if  an  organization  deals  with  a  reliable  ven- 
dor, they  minimize  the  risk  associated  with  maintaining  the 
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system.  The  organizations  options  are  broadened  in  that  if 
they  do  not  have  the  skills  or  personnel  available  to  main- 
tain the  system,  they  may  call  upon  the  assistance  of  the 
vendor  {at  the  established  rate) . 

There  are  a  great  number  of  software  packages  available 
that  are  marketed  as  aids  to  project  management  and  control. 
These  packages  vary  greatly  in  their  scope.  Some  are 
designed  to  assist  in  the  planning  and  tracking  of  only  one 
project,  others  will  handle  any  number  of  projects  and  pro- 
vide a  great  deal  of  flexibility  within  the  organization. 
The  problem  is  that  there  are  very  few  written  in  FORTRAN, 
the  preferred  language  for  implementation  at  FNOC. 

The  author  found  3  packages  that  were  available  in 
FORTRAN.  All  3  were  eliminated  from  consideration  because  it 
was  felt  that  they  would  not  meet  the  minimum  requirements. 
PAC  I  is  marketed  by  International  Sysytems  Inc.  (ISI), 
King  of  Prussia,  Pa.   This  package  is  designed  to  track 
only  1  projeqt  at  a  time  and  therefore  was  eliminated. 
P.D.F.-E.D.H.S.   is  available  from  Control  Data  Corpora- 
tion.  This  package  was  eliminated  due  to  its  strictly 
financial  orientation. 

OSCAR,  marketed  by  On-Line  Systems,  Pittsburgh,  PA. ,  is 
available  only  in  the  time  sharing  mode. 
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Failing  to  find  a  suitable  FORTRAN  software  package,  the 
author  chose  to  continue  the  search  under  the  assumption 
that  it  was  still  feasible  to  purchase  a  software  package 
and  lease  a  COBOL  compiler  for  less  cost  than  in-house 
development.  This  idea  will  be  discussed  further  in  chapter  8, 

An  examination  of  the  trends  and  the  state  of  the  art  in 
computer  programming  and  software  package  applications, 
along  with  a  preliminary  analysis  of  the  information 
requirements  of  a  project  information  and  control  system 
(PICS)  at  FNOC,  provided  a  background  for  establishing  the 
criteria  for  selecting  a  computer  software  package.   Woo- 
dridge,  [Ref.  17]  suggested  4  categories  for  software  selec- 
tion criteria.   These  criteria  address  requirements  in  the 
area  of  features,  technical  and  operational  environment, 
implementation,  and  price  of  the  package.   The  author  used 
these  4  categories  in  the  evaluation  of  the  available 
packages. 

A.   EVALUATION  CRITERIA  USED 
1 .   Features 

The  package  should  contain  as  many  of  the  features 
described  in  chapter  6,  section  B  as  possible. 
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2.   Technical  And  Operational 

It  must  be  possible  to  operate  the  package  in  the 
present  environment.   A  thorough  analysis  of  the  technical 
and  operational  features  of  the  candidate  packages  as  they 
relate  to  the  intended  environment  will  assist  in  an  appro- 
priate package  selection. 

a.  Hardware  Configuration 

The  package  must  be  capable  of  operating  on  the 
equipment  currently  available.   This  includes  the  available 
core  memory  as  well  as  peripheral  equipment  (ie.  card 
reader,  plotter,  printer,  etc.)   Mainframes  currently  at 
FNOC  available  include   3  CDC  6500s,  a  CYBER  175,  a  CYBER 
203,  a  CYBER  170/720,  and  2  PDP  11s. 

b.  Higher  Level  Language 

A  higher   level    language   such  as   FORTRAN   or   COBOL 
must   have  been   used    to    write   the   programs. 

c.  Operating  System 

The    package   should   be   capable  of  operating   under 
the   NOS/BE   operating  system. 

d.  Ease  Of   Use 

The  package  must  require  minimal  manual  inputs. 
In  other  words;  it  should  be  no  more  cumbersome  than  current 
manual  reporting  ,  record  keeping,  and  control  mechanisms  at 
FNOC. 
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e.   Flexibility 

incorporate  selected  current  procedures  and 
reporting  formats. 

3«   Implementation  And  3a.it  en  an  ee 

Two  necessary  requirements  which  ensure  that  the 
package  can  be  implemented  when  needed  and  maintained  with 
minimal  effort  are: 

a.  Immediate  Availability 

package  must  be  available  for  immediate  delivery 
and  implementation,  not  in  an  under  development  status. 

b.  Supplier* s  Reputation  And  Business  Integrity 
The  supplier   must  be  responsive  to  it  user*s 

problems.   They  must  be  a  well  established  company  with  a 
stable  professional  staff. 

c.   Training  And  Documentation 

Documentation  should  cover  the  system,  opera- 
tions, users,  data  preparation, and  programming.   It  should 
allow  for   ease  of  use  and  maintenance.   Training  should  be 
availablae  and  a  training  manual  available  for  inspection. 
4.   price 

Ideally,  the  package  should  be  available  to  the 
user  with  no  additional  start-up  costs. 

Software  directories  and  professional  publications  were 
searched  to  identify  feasible  candidate  packages. 
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Many  were  eliminated  immediately  because  they  were  not  capa- 
ble of  running  on  CDC  equipment.   The  following  packages 
were  thought  to  possess  most  of  the  desired  capabilities  and 
warrant  closer  review  and  examination  by  FNOC  professionals. 

B.   INTERNATIONAL  SYSTEMS1  PAC  II  [Ref.  18] 
1 .   General  Information 

International  systems  Inc.  (ISI) ,  King  of  Prussia, 
PA,  has  developed  a  sotware  package  for  project  management 
called  PAC  II.   ISI  specializes  in  automated  project  manage- 
ment systems.   Pac  II  performs  numerous  and  varied  functions 
as  depicted  in  Figure  8. 

Pac  II  is  a  totally  data  base  oriented  system,  con- 
sisting of  2  main  modules.   The  planning  module  uses  a  sin- 
gle, easy  to  use  input  sheet.   This  module  assists  the  user 
in  directing  and  scheduling  project  resources.   It  supports 
a  simulator  capability  with  critical  path  ident ificiation, 
resource  loading,  and  inter-project  dependencies.   Activi- 
ties can  be  assigned  to  resources  by  skill,  as  well  as  by 
specific  resource  identification.  In  fact,  PAC  II  is  capable 
of  making  proficiency  level  distinctions. 

The  management  module  accumulates  project  progress 
information  and  makes  available  multi-level  status,  cost, 
and  history  information.   A  single  turnaround  document, 
which  is  designed  by  the  user,  feeds  in  the  only  information 
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PAC  II  FUNCTIONS 

♦budgeting  *resource  tracking 

♦planning  *Progress  reporting 

♦project  simulation  ♦automatic  audit  trail 

♦critical  path  analysis  ♦status  accounting 

♦scheduling  ♦project  monitoring 

♦modelling  ♦cost  accounting 

♦skill  scheduling  ♦statistical  analysis 

♦on  line/real  time  ♦graphics 

Figure  8 


necessary  to  report  progress.   The  outstanding  feature  of 
this  module  is  its  ability  to  alert  management   early  when 
problems  occur.   The  user  sets  tolerance  levels  and  the 
updated  data  base  is  constantly  monitored.   Should  any  of 
these  limitations  be  broken,  PAC  II  automatically  alerts 
management  and  produces  detailed  reports  for  analysis  and 
corrective  action,  (ie.  projects  more  than  x  months  late  or 
cost  overruns  greater  than  x  percent)  This  is  a  particularly 
desirable  feature.   Project  managers  are  understandably  very 
reluctant  to  admit  their  project  is  behind  schedule.  This 
automatic  reporting  facility  alerts  upper  management  of  this 
type  of  problem. 
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Although  not  explicitly  termed  milestones,  the  same 
function  can  be  performed  by  defining  what   the  PAC  II  sys- 
tem refers  to  as  "EVENTS".   The  PAC  II  system  can  be  used 
to  plan  a  single  project  or  any  combination  of  projects,  Any 
number  of  activities  or  tasks  with  dependencies  across  pro- 
ject lines. 

PAC  II  offers  a  variety  of  input  methods:  computer 
generated  turnaround  document,  manual  input  forms,  punched 
cards,  terminal  entry,  or  OCR.   Table  entries  are  used  for 
those  items  of  information  that  are  placed  on  the  file  once 
only;  but  are  used  constantly  (ie.  skill  codes,  holiday 
schedule)  .   Use  of  table  entries  can  save  the  user  many 
repetitive  entries  and  provides  for  ease  of  maintenance  and 
modification. 

ISI  offers  a  seperate  add  on  option,  the  PAC  II 
Report  Writer,  a  facility  for  accessing  the  data  base  and 
producing  reports  that  have  not  already  been  programmed  into 
the  system.   This  facility  allows  the  user  to  request 
reports  in  a  format  they  specify.   Inputs  are  made  via  sim- 
ple English  language  statements.   ISI  also  offers  an  inter- 
active package  which  provides  a  terminal  data  entry  and 
planning  capability  and  a  graphics  package  which  offers 
users  2  different  options:  plotter  or  printer.  These 
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optional  software  packages  as  well  as  the  Report  Writer 
option,  may  be  purchased  with  the  basic  PAC  II  system  or  be 
added  on  at  a  later  date  if  desired. 

2.   Cost  Information 

" '        p  ^ — — 

Prices   in   effect   as   of   the    writing  of   this   thesis 
are  as   follows: 


PAC   II   basic  system 
plus    1    time    installation 
total 


cost   to   purchase  after 
one  year* 


bay 

lease/purchase 

$26,000 

$  15,60 0/yr 

$2,160 

$26,000 

$17,760 

$13,568 

optional   software  available 

PAC    REPORT    WRITER 
plus    1   time   charge 
total    (1    year) 

PAC    INTERACTIVE 
plus    1   time   charge 
total    (T   year) 


$4,000 


$10,000 


$2,U00/yr 
$      330 
$2,73  0 

$   6,000/yr 
$        830 
$6,830 


*7 
charge 


0%  of  the   first  years  lease  payment  and  installation 
will  be  applied  to  reduce  the  purchase  price. 
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Basic  package  price  includes: 

PAC  II  COBOL  source  programs  (on  tape) 

PAC  II  maintenance  and  enhancements  for  1  year 

pre  installation  meeting 

documentation 

*  implementation  guide  (2) 


*  coordinators  case  study  (1) 

*  users  reference  manual  (2) 

*  project  leaders  guide  (2) 


*  input  forms 

*  user  reference  cards  (25) 

*  selection  of  turnaround  documents 

installation,  checkout,  classes  and  OJT. 


3.   Additional  Information 

PAC  II  is  currently  installed  on  CDC  equipment  in 
several  areas.   Contact  was  made  with  MS.  Dee  Thorne  in  the 
data  processing  department  of  Reynolds  Electric  and  Engi- 
neering, Las  Vegas,  Nevada  [Hef.  19].   This  company  was  cho- 
sen because  it  not  only  has  a  PAC  II  package  installed  on 
CDC  equipment;  but  it  is  also  operating  under  the  NOS/BE 
operating  system.   This  organization  has  a  CDC  6400  and  a 
CYBER  74  operating  in  tandem.   Reynolds  is  the  prime  con- 
tractor for  the  Nevada  Test  Site  and  as  such,  they  utilize 
PAC  II  in  a  variety  of  applications,  including   R&D  develop- 
ment. 

Ms.  Thorne  indicated  that  they  have  received  excel- 
lent response  from  ISI  and  that  they  are  please  with  PAC  II. 
They  also  purchased  the  PAC  II  REPORT  WRITER  option;  but 
chose  to  develope  their  own  interactive  capability  in-house. 
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Ms.  Thome  is  very  agreeable  to  further  consultation  with 
FNOC  staff. 

C.   NICHOLS*  N5500  [Ref.  20] 
1 .   General  Information 

In  1977  Nichols  and  company  of  Los  Angeles,  CA. , 
developed  a  project  planning  and  control  system,  currently 
marketed  as  N5500.   PERT  and  precedence  networking  enable 
the  Nichols  system  to  constantly  monitor  the  impact  of  slip- 
pages and  plan  changes  on  in-process  projects.   What-if 
simulation  capabilities  highlight  the  impact  that  proposed 
projects  and/or  changes  will  have  on  the  current  in-process 
work  load.   Critical  path  analysis  and  slack  time  indica- 
tions provide  the  user   the  ability  to  optimize  schedules 
and  minimize  resource  waste. 

The  planning  process  starts  with  the  user*s  defini- 
tion of  the  organizations  planning  environment.   This  is 
accomplished  through  the  use  of  a  dictionary  mechanism. 
This  means  this  information  need  only  be  inputed  once,   the 
dictionary  is  maintained  seperately  from  the  rest  of  the 
data  which  makes  validation  and  modification  a  less  compli- 
cated task.   The  use  of  the  dictionary  also  allows  the  sys- 
tem to  be  adapted  to  any  life  cycle  methodology,  work 
breakdown  structure,  or  documentation  standards.   The  use  of 
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the  dictionary  mechanism  also  significantly  reduces  the 
redundant  entry  of  data.   This  means  a  time  and  effort 
savings  to  the  user. 

The  Nichols  system,  like  the  PAC  II  system,  has  an 
option  for  automatic  assignment  of  resources  by  the  system, 
which  can  be  valuable  to  the  planner.   Changes  to  projects 
can  be'  accomplished  with  remarkable  ease.   Tasks  may  be 
added,  changed,  or  deleted  at  any  time,  and  the  impact  of 
any  change  will  automatically  be  shown  on  all  related  tasks 
and  projects.   Task  changes  only  require  that  a  project  num- 
ber, task  number,  and  the  revised  data  be  entered. 

Project  control  is  accomplished  through  the  distri- 
bution of  work  schedule  reports  use  to  publish  work  assign- 
ments.  Each  person  or  group  then  reports  back  the  work  done 
on  each  task  during  the  week,  the  work  remaining  to  be  done 
on  each  in-process  task  for  that  week,  and  any  comments  they 
wish  to  call  to  the  project  managers  attention. 
The  Nichols  system  has  a  mechanism  where-by  an  overt  error 
in   a  data  field  will  not  cause  the  system  to  stop  perform- 
ing.  The  system  simply  makes  a  best  guess  and  executes  the 
program  regardless  of  the  number  or  severity  of  these 
errors.   Although  these  errors  are  flagged  and  continue  to 
be  flagged  until  corrected;  this  feature  should  be  closely 
examined  by  FNOC  analysts  to  determine  if  it  is  desirable. 
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The    Nichols  system    offers    20   report    formats   as   part 
of   its   basic   system.      These    reports   cover   6    major   groupings: 
administration,    project   planning  and  control,    resource   load 
and  distribution,    history   and  committment  of   resources,    per- 
formance  analysis,    and   accounting.      One   output   file   inter- 
faces  with   a    plotter  to   provide   critical   path   analysis. 
Other    reports  are   in   either   tabular   or   graphical  form   and 
are  easily   read   and   interpreted.      The   Nichols   system  also 
offers   an   optional  gsneralized  REPORT    WRITER    add  on   to   allow 
the  user   to    design   their   own   reports. 

The    weakness   in   the    Nichols   reporting   structure   lies 
in    the   fact    that   they    measure   progress   via    percent   completed 
rather   than    milestones    completed   which   can   be   very    mislead- 
ing.     The   variance   indicators  are   a   key   attraction,    drawing 
managements    attention   to   areas  that   are  off    target. 

2.      Cost   Information 

Prices   in  effect  as   of  the    writing   of   this   thesis 
are  as   follows: 

BOY  Lease/Purchase 

N5500    Basic    System  $25,000  $15,000/yr 

plus    1    years    maintenance  n/a  $    1,000/yr 

total    (1    year)  $16,000 

Cost   to  purchase  after  ^..    _Art 

1    year  n/a  $11,500 

OPTIONAL   SOFTWARE   A7AILABLE    (not   available  as   lease) 

REPORT    WRITER  $    5,000 

Interactive  $10,000 
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Package  price  includes: 

object  code  (source  will  be  delivered  on  tape  upon  receipt  of 
payment)  r 

technical  documentation  (1) 

user  manuals  (5) 

5  days  of  on  site  training 

input  forms 

1  year  maintenance  with  purchase 

3.   Additional  Information 

Tektronics,  a  production  facility  that  among  other 
things  produces  terminals.   N5500  was  originally  installed 
on  a  CYBER  73;  but  due  to  work  load  constraints,  they 
switched  to  their  CYBER  175.  This  action  resulted  in  faster 
turnaround  time.   The  operating  system  being  utilized  is  NOS 
level  509. 

Contact  was  made  with  Ms.  Charlene  Madiman,  who  is 
the  data  base  administrator  for  the  Product  Safety  Division. 
[Ref.  21]  She  is  responsible  for  data  entry   and  interpreta- 
tion in  support  of  the  N5500  applications.   Ms.  Madiman 
indicated  that  they  were  very  pleased  with  the  N5500  pack- 
age.  Their  input  is  done  via  terminal  and  then  batched  into 
the  system  for  processing.   All  data  entry  and  interpreta- 
tion is  done  by  Ms.  Madiman  and  she  says  this  is  a  full  time 
job  considering  the  number  of  projects/instruments  she  works 
with  (over  350) .   Inputs  from  project  managers  is  very 
straight  forward  and  involves  entries  on  a  pre-printed  form. 
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Only  two  negative  aspects  were  reported.   First,  that  the 
previous  version  of  the  user  manual  was  difficult  to  inter- 
pret.* The  second  problem  area  was  in  the  error  handling 
mechanism.   Errors  are  flagged  and  continue  to  be  flagged 
until  corrected;  however  there  is  no  indication  as  to  the 
type  of  error.   Error  correction  may  prove  to  be  very  time 
consuming  if  the  error  is  not  readily  apparent. 

Ms.  Madiman  indicated  that  their  staff  would  be 
happy  to  discuss  the  package  and  its  implementation  further 
with  FN03  staff.**  Ms.  Cindy  Wong,  marketing  representative 
for  Nichols,  has  indicated  that  there  is  a  good  chance  that 
N5500  will  be  converted  to  NOS/BE  for  another  customer  in 
the  near  future  [Ref.  22]. 

D.   MSP»S  PROJECTMANAGER  [Ref.  23] 
1 .   General  Information 

PROJECTMANAGER  was  marketed  originally  in  1972  under 
the  name  PMACS.   It  is  a  batch  processing  system  which  main- 
tains 3  major  files:   the  resource  file,  the  activity  file, 
and  the  project  files.   Generally,  the  resource  file  and  the 
activity  file  need  only  be  set  up  once.   The  project  file 


♦Nichols  has  released  a  new  version  of  the  user  manual; 
however  Ms.   Madiman  has  not  used  it  long  enough  to  evaluate 
it. 

**Contact  point  is  Imants  Goltz,  manager  of  software 
support,  at  (503)  627-4675. 
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activity  file  need  only  be  set  up  once.   The  project  file 
contains  the  project  plan,  estimates,  progress  to  date,  and 
new  projects  as  required.   Projects  can  be  broken  down  into 
subproject  levels  called  tasks. 

PROJECTMANAGER  requires  periodic  updating  of  work 
accomplished  and  costs  incurred.   The  user  selects  the 
reporting  period.   Mandatory  entries  are  resource,  project, 
and  activity  codes.   Optional  entries  include  task,  rate  of 
pay,  computer  use  codes  as  well  as  various  expence  catego- 
ries and  projection  data  items. 

Input  can  be  by  card,  or  card  image  on  magnetic 
media,  paper  tape,  or  on-line  data  entry.   All  input  tran- 
sactions are  read  into  the  system  by  a  data  validation  pro- 
gram, which  carries  out  exhaustive  validation  of  each  input 
record  and  rejects  any  erroneous  data.   A  report  is  produced 
by  the  program  so  that  all  detected  errors  are  clearly 
described  to  the  user  for  correction  and  resubmission. 

PROJECTMANAGER  output  consists  of  3  main  types: 
validation  reports,  file  content  listings,  and  user  selected 
progress  reports. 

Validation  reports  are  produced  whenever  data  is  entered. 

All  input  information  is  printed  including  error  codes  and 

pointers  that  identify  incorrect  items. 
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File  content  listings  are  obtained  on  demand  in  standard 
format  and  are  of  particular  interest  to  those  who  control 
code  allocation  and  related  tasks. 

Progress  reports  can  customize  the  system  to  the  needs  of 
the  organization.   The  number  and  type  of  the  output 
reports  is  determined  by  the  user. 

2.  Cost  Information 

The    PROJECTMANAGER    package   can    be  purchased   for 
$8,000.    The    package   includes: 

Object   code    (on  tape) 

1    days  on-site  training   and  advise 

1   set  of   documentation 

3.  Additional  Information 

Because  of  the  relatively  low  cost,  this  package  was 
included  for  consideration,  even  though  it  has  not  been 
implemented  on  CDC  equipment  and  will  require  some  in-house 
effort.   The  package  was  written  in  C030L  for  IBM  eguiment; 
but  has  been  coverted  to  operate  on  Burroughs,  Honeywell, 
and  ICL  equipement.   A  recent  conversion  from  IBM  to  ICL 
DME/V  took  one  user  group  17  days.   Larry  Hagg,  West  Coast 
Region  Manager  fo  MSP,  has  indicated  that  FNOC  could  obtain 
the  source  program  at  no  additional  charge,  if  they  wished 
to  convert  the  package  themselves.  [Ref.  24]  The  code  should 
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bs  examined  closely  by  FNOC  analysts  to  determine  if  there 
would  be  any  problem  in  conversion.   Generally  speaking, 
conversion  of  COBOL  programs  is  relatively  easy.   The  prob- 
lem is  that  once  FNOC  makes  this  conversion,  MSP  will  not  be 
able  to  provide  the  maintenance. 

E.   OTHER  PACKAGES  EXAMINED 

Other  packages  examined  and  subsequently  eliminated  are 
included  here  to  assist  FNOC  in  acquisition  in  the  event 
that  they  choose  to  follow  through  on  a  PICS.   QUICK  TEOL, 
marketed  by  Quality  Data  Products  Inc.,  is  written  in 
assembly  language  and  can  not  be  adapted  to  CDC  equipment. 
PROJECT  MONITOR,  Marketed  by  Program  Products  Inc,  was 
unresponsive  to  requests  for  additional  information.   Infor- 
mation on  PC  70,  marketed  by  Atlantic  Software  Inc.,  was 
received  to  late  to  include  in  this  analysis.   It  is  recom- 
mended; however  that  should  FNOC  consider  the  purchase  of  a 
software  package,  Atlantic  Software  Inc.  Be  given  an  invita- 
tion for  bid. 
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VIII.  ALTERNATIVE  COURSES  OF  ACTION 

A.  MANUAL  ALTERNATIVES 

The  alternatives  requiring  the  least  time,  effort,  and 
resources  are  those  that  require  little  change  to  current 
methods;  however  these  alternatives  may  not  be  the  most 
desirable.   Two  manual  alternatives  are  presented  here 
because  they  are  considered  viable  alternatives. 
ALTERNATIVE  1:  CONTINUE  AS  IS 

The  obvious  advantage  to  this  alternative  is  that  it 
requires  no  effort  and  no  cost.   That  is,  no  direct  cost. 
It  could  cost  in  terms  of  the  efficiency  and  effectiveness 
of   the  organization.   With  the  exception  of  the  work  unit 
reporting,  which  is  done  twice  a  year,  there  is  no  formally 
defined  reporting  structure  for  project  management  at  FNOC. 
Formal  reporting  permits  ready  comparison  of  progress  with 
plans  and  ensures  a  uniformity  and  consistency  of  informa- 
tion throughout  the  project.   It  also  provides  a  historical 
record  of  tLe  project.   Failure  to  keep  adequate  well  struc- 
tured reports  makes  it  very  difficult  when  others  are  forced 
to  assume  management  duties.  Personnel  turnover  at  FNOC  is 
high  due  to  the  military  environment.   It- is  therefore 
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critical  that  records  allow  the  new  project  manager  to  trace 
what  has  been  done  and  what  remains  to  be  done  in  the  pro- 
ject.  Many  projects  span  several  years,  so  the  chance  of 
turnover  in  project  personnel  is  high.   Use  of  civilians  in 
ksy  positions  eases  this  problem  somewhat;  but  does  not  eli- 
minate it  all  together. 

With  no  complete  historical  records  of  projects,  FNOC 
will  find  great  difficulty  in  presenting  and  defending  their 
actions  in  case  of  contract  dispute  and  litigation.   Histor- 
ical records  of  a  project  can  also  assist  the  project  man- 
ager in  planning  future  projects  and  hopefully,  in  avoiding 
mistakes  made  in  prior  projects. 
ALTERNATIVE  2:  ENHANCED  MANUAL  SYSTEM 

Enhancement  of  the  current  manual  system  could  serve  to 
alleviate  some  of  the  problems  noted  previosly.   This 
enhancement  can  take  the  form  of  in-house  establishment  of 
definitions  and  procedures  or  perhaps  the  purchase  of  a  pro- 
ject management  methodology. 

In-house  enhancement  means  those  who  establish  the  meth- 
odology will  be  intimately  familar  with  the  FNOC  environ- 
ment; however  they  may  not  have  the  project  management 
expertise  that  might  be  available  on  the  outside.   Staff 
time  will  still  be  required  to  determine  amd  put  into  effect 
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the  methodology.   This  may  be  time  that  could  be  better 
spent  elsewhere. 

There  are  several  methodologies  marketed  that  would  pro- 
vide assistance  in  establishment  of  a  project  management  and 
control  system.   Spectrum,  marketed  by  Spectrum  Interna- 
tional Inc.  of  Los  Angeles, CA.,  and  SDM/70,  marketed  by 
Atlantic  Software  Inc.  of  Philadelphia,  PA.,  are  two  such 
methodologies.   Spectrums  price  ranges  from  332,000.   Price 
is  dependent  on  the  number  of  programmers  and  analysts  that 
must  be  trained.   For  a  staff  of  40-50,  the  price  goes  up  to 
$50,000  ,  which  includes  the  16  days  of  training.   The 
SDM/70  price  of  $30,000  includes  training  and  the  availabil- 
ity of  a  24  hour  hot  line.   These  prices  are  relatively  high 
in  comparison  to  the  automated  packages  available.   They 
also  fail  to  eliminate  a  key  problem,  relating  to  timeliness 
and  accuracy  of  reports.   The  amount  of  correlation  and 
calculations  needed  to  produce  some  reports  preclude  the  use 
of   manual  methods.   Speed  and  accuracy  are  vital  parts  of 
progress  reporting  and  are  primary  benefits  accorded  by  a 
computer. 

B.   AUTOMATED  ALTERNATIVES 

Projects  involve  the  deployment  of  a  number  of  person- 
nel, equipment,  and  loney,  and  the  integration  of  activities 
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to  achieve  some  predetermined  aim.   This  means  that  these 
activities  must  have  been  pre-planned,  and  the  degree  of 
success  achieved  depends  to  a  large  extent  on  the  effective- 
ness of  the  planning.   There  are  many  types  of  projects  and 
activities  that  do  not  lend  themselves  to  manual  control 
methods,  for  example,  those  that  involve  a  large  number  of 
organizations  or  people.   Additionally,  the  interdependen- 
cies  of  the  various  parts  of  the  plan  may  be  to  complex  for 
an  individual  to  monitor  and  traditional  methods  of  repre- 
sentation (ie.  bar  charts  or  schedules)  may  not  represent 
the  plan  effectively.   Finally,  the  project  may  span  long 
lengths  of  time,  making  it  difficult  to  track  manually. 
With  these  points  in  mind,  it  becomes  necessary  to  consider 
alternatives  that  provide  for  some  means  of  automated  assis- 
tance for  PICS.   The  following  alternatives  provide  that 
capability. 
1LTEEHATIVE  3:  IN-HOUSE  DEVELOPMENT 

There  are  several  advantages  to  in-house  development. 
First,  the  system  must  be  acceptable  within  the  user  envi- 
ronment and  to  the  user  group.   By  developing  it  in-house 
there  is  a  greater  opportunity  for  user  involvement.   The 
user  must  identify  tha  new  system  with  their  operational 
requirements  from  the  start,  this  too  is  made  more  viable  by 

68 


in-house  development.   Change  needs  to  be  self-motiviated  if 
it  is  to  be  successful  and  long  lasting.   The  organization 
must  take  the  responsibility  for  and  be  committed  to  the  new 
program. 

In-house  system  development  is  rarely  cost-effective 
when  compared  with  outside  purchase.   Valuable  system  usage 
time  is  lost  while  the  in-house  system  is  developed.   Due  to 
the  developmental  nature,  there  is  a  degree  of  uncertainty 
as  to  the  cost  and  schedule  completion.   Additionally,  staff 
must  be  allocated  to  the  development,  who  may  be  utilized 
more  effectively  on  organization  specific  development  (ie. 
oceanographic  and/or  meterological  products) .   The  mainte- 
nance/enhancement cost  of  in-house  software  is  normally  in 
the  region  of  50%  of  the  original  cost  per  year.   While  it 
is  true  that  in-house  systems  may  be  geared  more  closely  to 
the  original  requirements;  this  may  make  them  less  flexible 
when  ammendments  become  necessary. 
ALTERNATIVE  4:  PURCHASE  SOFTHARE  PACKAGE 

It  would  be  advantageous  to  puchase  a  software  package 
rather  than  suffer  the  expense  and  time  delay  that  would  be 
necessary  to  design  and  program  a  PICS  specifically  for  FNOC 
applications.   Because  the  vendor  is  able  to  spread  his 
package  development  costs  across  a  number  of  installations; 

69 


it  represents  a  real  discount  on  the  investment  required  for 
a  similar  development  in-house.   Funds  can  be  budgeted  and 
an  installation  date  scheduled  with  a  great  deal  more  cer- 
tainty.  The  organization  also  gains  the  value  of  the  ven- 
dors project  management  expertise  and  the  experience  gained 
by  installations  at  other  sites.   Additionally,  many  of  the 
software  bugs  will  have  been  corrected.   The  problem  is  that 
the  organization  may  not  be  as  receptive  to  a  package  that 
will  change  their  methods.   It  will  be  important  to  make  the 
transition  as  painless  as  possible.   Many  of  the  packages 
allow  the  user  to  define  terms  and  establish  procedures  con- 
sistent with  those  currently  in  use.   The  organization  must 
assure  that  documentation  is  complete  since  they  may  be 
required  to  maintain  it  or  puchase  maintenance  services  from 
the  vendor  at  additional  costs. 

Purchase  of  a  software  package  will  probably  require 
purchase/lease  of  a  COBOL  compiler  since  very  few  packages 
are  written  in  FORTRAN.   Contact  was  made  with  Mr.  Ken  Gat- 
liffe,  local  CDC  representative,  concerning  pricing  informa- 
tion. A  COBOL  compiler  for  a  CYBER  170,  175  or  CDC  6600 
would  cost  $12,540  to  purchase  or  may  be  leased  for  $310  a 
month  plus  a  one  time  fee  of  $140  [Ref.  25]. 
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ALTERNATIVE  5:  HSVIVE  OLD  HIS 

The  FNOC  MIS  system  was  originally  designed  for  use  by 
one  department  head  and  later  adopted  for  command-wide  use. 
It  was  not  designed  with  the  organizations  overall  objec- 
tives in  mind.   It  was  designed  to  fill  a  particular  need  at 
that  time.   The  designer  of  the  program  and  those  that  had 
been  directly  involved  in  its  operation,  have  long  since 
departed  FNOC.   Documentation  is  not  complete  and  therefore 
revision  and/or  updating  will  not  be  an  easy  task.   It  will 
take  a  great  deal  of  time  for  someone  to  become  familar 
enough  with  the  code  to  start  to  adapt  it.   Additionally, 
there  are  still  some  very  negative  attitudes  remaining  con- 
cerning this  MIS  .   It  was  never  well  defined,  inputs  and 
updates  were  erratic,  and  the  system  only  received,  sporadic 
attention  by  upper  management.   Not  only  did  middle  manag- 
ers, who  were  required  to  submit  the  update  information,  not 
derive  any  benefits  from  the  system;  but  they  saw  that  upper 
management  was  not  utilizing  it.   They  saw  their  efforts  as 
wasted,  and  when  they  did  see  any  outputs  from  the  system  it 
was  not  current  information. 

This  system  required  at  least  1  full  time  administrator, 
although  2  would  be  more  realistic  considering  the  amount  of 
data  entry  required.   If  the  documentation  were  clear  enough 

71 


ana  only  minor  changes   were  needed,  this  would  clearly  be 
an  economical  approach.  The  ramifications  of  the  staff  atti- 
tude problem  is  indeed  difficult  to  predict. 
ALTERNATIVE  6:  DEDICATED  HIHI 

Initially  this  alternative  will  be  the  most  costly.   Not 
only  will  the  organization  need  to  purchase  the  computer; 
they  will  also  have  to  purchase  or  develop  the  software 
package.   This  alternative  will,  in  all  liklihood,  take  more 
time  from  decision  to  installation  than  the  others.   It  will 
also  require  the  involvement  of  more  FNOC  technical  person- 
nel in  the  acquisition,  due  to  the  hardware. 

This  alternative  has  several  distinct  advantages.   Hav- 
ing a  dedicated  or  semi-dedicated  mini  makes  access  easier 
and  allows  for  continued  operations  when  the  main  computer 
system  goes  down  or  is  over  loaded.   It  also  allows  the  pos- 
sibility of  a  wider  selection  of  software  packages.   Greater 
benefits  may  be  derived  by  utilizing  the  mini  for  other  man- 
agement and/or  administrative  applications,  such  as  an 
inventory  control  system,  electronic  mail,  etc.   It  also 
would  open  up  a  wider  range  of  possible  software  packages 
for  this  and  other  applications. 
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IX.    CONCLUSION    AND    RECOMMENDATIONS 

Project    managers  are   responsible   for  planning   and  sche- 
duling  various   projects   and   assignments.      They   must   face 
changing  priorities  and   resources   and   respond   appropriately. 
Changes   and   reevaluation  of    projects   involving   new    priori- 
ties,   resource   availability    (or   lack   of   availability) ,    new 
dependencies,    ect.    make   management   of   on   going   projects    a 
full  time   job. 

A    highly   complex  and   expensive    undertaking   like   a  soft- 
ware  development   project  requires   careful   planning.      The 
project  manager   can   not  hope   to   schedule,    measure,    and  con- 
trol complex    programming   activity   without   a   formalized, 
highly   developed  plan.      All   projects   need  planning.      In    most 
cases   this   involves   a   detailed  breakdown  of   all   the   tasks 
which   make  up  a    project   to   ensure   that   realistic  schedules 
of   anticipated   progress   can   be  prepared.      Each   task   needs  to 
be   of   an  easily   identifiable  and   self   contained   nature   so 
that   measurement   of   progress   is   made   as   simple  as  possible. 
Within  each    tasR  self   contained  check   points   must   be   estab- 
lished so  that   comparison    of  actual   progress   against   planned 
progress  can   be    made   at   meaningful   intervals. 
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The  only  realistic  way  to  be  in  control  is  to  see  regu- 
lar evidence  of  progress  (evidence  of  tasks/jobs  completed)  . 
Documents  to  control  projects  must  take  into  account  a 
balance  between  the  need  for  control;  and  the  desire  to  keep 
form  filling  to  a  minimum. 

One  of  the  more  important  features  of  the  project  con- 
trol system  is  the  method  of  reporting.   It  should  serve  to 
formalize  the  kind  of  casual  reporting  that  occurs  in  all 
organizations.   Formal  reporting  permits  ready  comparison  of 
progress  with  plans  and  ensures  a  uniformity  and  consistency 
of  information  throughout  the  project. 

It  is  the  authors  opinion  that  FNOC  needs  a  better 
defined  and  more  uniform  project  information  and  control 
system.   The  current  formal  reporting  mechanism  and  the 
informal  reporting  to  the  commanding  officer,  are  neither 
adequate  nor  efficient.   Verbal  reports  to  the  commanding 
officer  are  time  consuming  and  may  not  be  the  best  presenta- 
tion mode.   Presentation  of  one  project  without  a  view  of 
how  it  fits  into  the  overall  project  environment  may  give  a 
distorted  picture.   Use  of  the  word  processor  for  anything 
other  than  processing  textual  information  is  not  authorized, 
therefore  correlation  of  information  must  be  accomplished  in 
some  other  manner  [Ref.  26  &   27]. 
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It  is  also  the  authors  opinion  that  correlation  and 
presentation  of  project  information  can  best  be  accomplished 
by  an  automated  PICS, 

Based  on  information  obtained  in  the  preliminary  analy- 
sis, the  author's  preference  is  for  the  PAC  II  software 
package.   This  is  based  primarily  on  2  findings.   First,  the 
fact  that  this  system  has  been  implemented  successfully  on 
CDC  equipment  and  the  same  operating  system  as  utilized  at 
FNOC.   Additionally,  this  package  appears  to  be  flexible 
enough  to  meet  current  and  possible  fututre  needs  of  FNOC. 

Although  it  is  the  author*s  opinion  that  adoption  of  an 
automated  project  information  and  control  system  at  FNOC  is 
a  desirable  action;  and  that  this  action  if  properly  imple- 
mented will  enhance  FNOC«s  effectiveness  and  efficiency;  the 
following  must  serve  to  qualify  this  recommendation. 

The  first  and  primary  consideration  for  implementation 
is  that  top  level  management  at  FNOC  must  make  the  decision 
to  give  full  and  active  support  to  such  a  system.   Without 
this  support  the  system  has  very  little  chance  for  success. 
Positive  action  must  be  taken  if  requirements  are  not  met  by 
principle  investigators  and  project  managers.   A  steering 
committee,  whose  primary  function  is  to  review  procedures 
and  assure  compliance,  might  be  considered. 
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Once  the  decision  is  made  to  provide  this  support,  an 
evaluation  group,  composed  of  programmers,  analysts,  project 
managers  and  principle  investigators,  should  be  formed.   The 
Executive  Officer  and/or  the  Commanding  Officer  may  also 
wish  to  be  a  part  of  this  group  since  they  are  also  users. 
Acquisition  must  go  out  for  competitve  bid  unless  sole 
source  can  "be  justified,  which  is  unlikely  in  this  case. 
Distributors  of  all  packages  reviewed  offered  demonstrations 
and/or  presentaions  of  their  package  capabilities.   It  may 
be  appropriate  to  allow  vendors  to  make  a  presentation  prior 
to  the  decision  to  automate.   It  would  certainly  serve  to 
provide  visual  proof  of  what  an  automated  system  can  and  can 
not  do. 

Once  a  package  is  selected;  it  is  recommened  that  in 
order  to  minimize  the  disruption,  FNOC  not  convert  in-pro- 
cess projects  to  the  new  system.   It  would  be  best  to  start 
only  new  projects  on  the  new  system.   This  will  minimize  the 
burden  on  the  staff  and  management  personnel  and  allow  for  a 
smoother  transition. 

The  development  and  implementation  of  a  project  control 
system  is,  in  itself  a  project,  k    great  deal  of  extra 
effort  is  needed.   Just  how  detailed  any  project  control 
system  becomes  is  a  function  of  the  system  size  and 
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complexity  of  the  organization  in  which  it  is  being  applied, 
Generally,  whatever  the  effort,  the  cost  of  a  typical  soft- 
ware development  project  is  reason  enough  to  justify  it. 
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APPENDIX  A 
Requirements  Checklist 
GENERAL  INFORMATION 

This  checklist  is  part  of  a  study  being  conducted  on  pro- 
ject management  and  control  at  FNOC.  The  information  on  the 
following  pages  was  acquired  as  a  result  of  interviews  con- 
ducted with  a  select  group  of  key  FNOC  project  personnel. 
The  question  posed  was;  what  information  requirements  and/or 
capabilities  would  you  like  to  see  in  a  project  management 
and  control  system  at  FNOC  (either  automated  or  manual) . 

The  requirements  listed  on  the  following  pages  represent 
ONLY  those  that  were  mentioned  during  the  personal  inter- 
views. The  list,  in  all  probability,  does  not  cover  all  pos- 
sible requirements.  It  is;  however,  a  starting  point. 

The  requirements  have  been  grouped  according  to  six 
general  functional  categories  to  facilitate  an  orderly 
presentation  mode.  This  categorization  was  based  strictly  on 
the  subjective  judgement  of  the  interviewer.  Some  of  the 
requirements  could  very  well  fit  into  more  than  one  of  the 
categories;  however  they  are  listed  only  once  for 
simplicity. 
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DIRECTIONS 

Your  cooperation  is  requested  in  reviewing  and  responding 
to  the  checklist  items  on  the  following  pages.  Each  item 
requires  two  checks;  Dne  in  response  to  whether  or  not 
you'll  use  the  information  and  one  in  regards  to  how  you 
would  prefer  it  to  be  stored. 

If  after  reviewing  these  requirements  you  can  add  to  the 
list  please  do  so;  your  input  will  be  a  valuable  addition. 
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